REMARKS 

Claims 1-21 are currently pending. In an Office Action dated July 2, 2007, 
claims 1 -2 1 were rejected. Applicants thank the Examiner for carefiiUy considering the 

present application. 

By way of this Amendment and Response, claims 1,8-11,16, and 21 have been 
amended, and claims 7 and 19 have been cancelled. No claim is added. 

Objections To Drawings 

The Office Action Summary indicates that the drawings filed on July 3, 2003 are 
objected to by the Examiner. However, the Detailed Action does not specify any reason 
for the objection. 

Applicants note that a Notice to File Missing Parts of Nonpro visional Application 
dated October 1, 2003 required Applicants to submit replacement drawings in compliance 
with 37 CFR 1.84 and 37 CFR 1.21. Apphcants subsequently submitted replacement 
drawings for FIGS. 5 and 6 together with a response to the Notice on November 25, 
2003. 

Applicants respectfully request the Examiner withdraw the objection, or alterna- 
tively, specify grounds of the objection. 

Response to Rejection Under 35 USC 103(a) in View of Nakayama 
and RFC 3031 

In the 2nd paragraph of the Office Action, the Examiner rejected claims 1-21 un- 
der 35 USC § 103(a) as allegedly being unpatentable over U.S. Patent No. 6,907,001 
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("Nakayama") in view of "MPLS Architecture" by Rosen, IETF RFC 3031, January 2001 
("RFC 303 1 "). This rejection is now traversed. 

Independent claim 1 as amended recites a method for processing a packet in a 
multi-slice network processor system. The method recites, among other limitations, 
"delivering one or more cells of the packet to one or more processing slice modules based 
upon load balancing criteria; storing one or more cells in a buffer in the packet shce; and 
generating a buffer correlation data structure correlating the buffer of the packet slice." 
The above claimed feature can improve the performance of the multi-slice network proc- 
essor system. Independent 16 as amended recites similar limitations. 

Nakayama and FRC 3031, either alone or in combination, fail to disclose this 
claimed feature. Nakayama discloses a packet switch that converts received variable 
length packets to fixed length cells, switches the cells, restores the cells back to the vari- 
able length packets, and sends out the restored variable length packets. See Nakayama, 
Abstract. Different from the claimed invention, Nakayama' s switch writes cells into "a 
plurality of cell queues in the input buffer memory 15 according to the output line num- 
ber and service class of the ATM cell header." See Nakayama, col. 7, lines 33-39, and 
col. 15, lines 42-47. Both the output line number and the service class of ATM cells are 
specified in the header of the received packet. See Nakayama, claim 1 (output line is 
specified in header information of the packet) and col. 7, lines 12-14 (the service class is 
specified with the TOS field of the IP header). Therefore, Nakayama teaches placing 
ATM cells in cell queues predetermined by associated packets, and is totally silent as to 
delivering cells to processing slice modules based upon load balancing criteria. Thus, 
the Nakayama system fails to teach "delivering one or more cells of the packet to one or 
more processing slice modules based upon load balancing criteria." 
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RFC 303 1 also fails to disclose the above cited element. RFC 303 1 specifies an 
Internet standards track protocol. See RFC 303 1 , page 1 . RFC 303 1 discloses that it is 
desirable to do load balancing over multiple equal-cost paths when routing a packet by a 
label switch routers. See RFC 3031, sections 3.11 and 3.12. However, cells as 
claimed in claim 1 are different from packets (data of a packet is segmented into cells). 
In addition, cells of a packet may be delivered to different processing slice modules in the 
claimed invention, while data of a packet are always routed to a same label switch routers 
in RFC 303 1 . Load balancing among routers is not the same as load balancing among 
processing slice modules within a multi-slice network processor system. Thus, RFC 
303 1 also fails to teach "delivering one or more cells of the packet to one or more proc- 
essing slice modules based upon load balancing criteria." 

Likewise, the combination of Nakayama and RFC 3031 also fails to disclose or 
suggest the claimed features cited above. As discussed above, the above claimed fea- 
ture is not disclosed in either reference. However, even if the two references were com- 
bined, at best the combination provides a system and method for switching packets by 
converting them into fixed length cells, and for routing the packets over muhiple equal- 
cost paths by conducting load balancing. This is not what Applicants claim. This is 
not a configuration in which a packet is segmented into cells and the cells are delivered to 
one or more processing slice modules based upon load balancing criteria. 

Aspects of independent claim 1 related to storing one or more cells in a buffer in 

the packet slice and generating a buffer correlation data structure correlating the buffer of 
the packet slice were previously recited by claim 7, which were rejected as obvious over 
Nakayama, RFC 303 1 , and official notice. The Examiner took official notice that using 
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data structure such as link list and tree to present a group of cells/packets is well known 
to a person skilled in the art. 

Applicants respectfully traverse this official notice. Assertions of technical facts 
in areas of esoteric technology or specific knowledge of the prior art must be supported 
by a citation to some reference work recognized as standard in the pertinent art. In re 
Ahlert, 424 F.2d 1088, 1091 (CCPA 1970), MPEP 2144.03 A. Whether it is well 
known to generate correlation data structure correlating buffers of packet slice is an area 
of esoteric technology, and is not capable of instant and unquestionable demonstration as 
being well-known. Accordingly, Applicants respectfully request that the Examiner pro- 
vide documentary evidence supporting this rejection. 

In view of the above, Nakayama and RFC 3031, whether considered individually 
or in combination, fail to disclose each and every limitation recited in amended inde- 
pendent claims 1 and 16. Thus, independent claims 1 and 16 are patentable over Naka- 
yama and RFC 3031. Dependent claims 2-6, 8-15, 17, 18, 20, and 21 are allowable for 
at least the same reasons. 

In addition, claim 5 stands rejected as obvious over Nakayama and RFC 303 1 . 
Claim 5 recites a feature of "delivering body data of the packet to one or more of the 
processing slices ahead of the header data of the packet." Therefore, the claimed inven- 
tion may deliver data of a packet out of sequence. 

The Examiner cited col. 8, lines 47-48 of Nakayama for support of the rejection of 
claim 5 . However, the cited section merely suggested that priority cells and non-priority 
cells destined for the same output port are stored in a mixed state in one cell queue and 
are read out in FIFO fashion in their arrival sequence. Because in Nakayama cells gen- 
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erated from the same packet are stored in the cell queue in sequence (see Nakayama, col. 
7, lines 19-39), cells containing body data of a packet in Nakayama will not be delivered 
ahead of cells containing header data of the packet. In addition, RFC 303 1 is totally si- 
lent as to delivering body data of a packet to a processing slice ahead of header data of 
the packet. Therefore, Nakayama and RFC 303 1 , whether considered individually or in 
combination, fail to disclose each and every limitation recited in claim 5. 

Claim 9 stands rejected as obvious over Nakayama, RFC 3031, and official no- 
tice. Claim 9 recites "maintaining an independent set of upper bits of a sequence num- 
ber for each communication flow; and responsive to detecting one of the processing 
slices delivering a sequence number that is smaller in value than an immediately preced- 
ing sequence value for the same slice, incrementing the independent set of upper bits for 
the respective communication flow, concatenating the set of upper bits with a set of bits 
of the sequence number into an index, indexing into a re-sequencing buffer space of suf- 
ficient depth to cover a slice-to-slice skew case based on the index, and resequencing the 
packet into its sequence order position." The Examiner took official notice that using 
large enough sequence number to present maximum number of sequence and using 
minimum bits to present a sequence number in order to save precious space in header of 
the packet/cell is well known in the art. 

Applicants respectfiilly submit that whether it is well known to respond to detect- 
ing one of processing slices delivering a sequence number that is smaller in value than an 
immediately preceding sequence value for the same slice by incrementing the independ- 
ent set of upper bits for the respective communication flow, concatenating the set of up- 
per bits with a set of bits of the sequence number into an index, indexing into a re- 
sequencing buffer space of sufficient depth to cover a slice-to-slice skew case based on 
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the index, and resequencing the packet into its sequence order position is an area of eso- 
teric technology, and is not capable of instant and unquestionable demonstration as being 
well-known. Accordingly, Applicants respectfully request that the Examiner provide 
documentary evidence supporting this rejection. 

Similar to claim 9, claim 10 stands rejected as obvious over Nakayama, RFC 
303 1 , and official notice. Claim 1 0 recites "generating a slice correlation data structure 
for the packet including a packet reference pointing to the buffer of the packet shce in- 
cluding the first cell of the packet, and a respective buffer indicator for the buffer in each 
packet shce storing the first cell in the slice for the packet; and entering the slice correla- 
tion data structure as a single queue entry into a queue." The Examiner took official 
notice that using a double link list data structure to present a packet is well known in the 
art. 

Applicants respectfully submit that whether it is well known to generate a slice 
correlation data structure for the packet including a packet reference pointing to the 
buffer of the packet slice including the first cell of the packet, and a respective buffer in- 
dicator for the buffer in each packet slice storing the first cell in the slice for the packet is 
an area of esoteric technology, and is not capable of instant and unquestionable demon- 
stration as being well-known. Accordingly, Applicants respectfully request that the Ex- 
aminer provide documentary evidence supporting this rejection. 

Therefore, withdrawal of the § 103 rejections is respectfiiUy requested. 
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Conclusion 

In sum, Applicants respectfully submit that claims 1-6, 8-18, 20, and 21, as pre- 
sented herein, are patentably distinguishable over the cited references. Therefore, Ap- 
plicants request reconsideration of the basis for the rejections to these claims and request 
allowance of them. 

Should the Examiner wish to discuss the above amendments or if the Examiner 
believes that for any reason direct contact with Applicants' representative would help to 
advance the prosecution of this case to finality, the Examiner is invited to telephone the 
undersigned at the number given below. 

Respectfully submitted, 
Harish R. Devanagondi, et al. 

Dated: October 2. 2007 By: /Jie Zhang/ 



Jie Zhang, Reg. No. 60,242 
Fenwick & West LLP 
801 California Street 
Mountain View, CA 94041 
Phone: (650) 335-7194 
Fax: (650) 938-5200 
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